在軟體開發時常聽到一個鬼故事「XXX 功能好像怪怪的，你可以幫我看一下嗎？」，這時候心裡 OS：「啥怪怪的我弄很正常啊？」接下來開始要使用第二技能「通靈」來確認怪是個怎樣的怪法，但這往往都需要花費大量的時間和精力。

以上的情境在軟體開發中頻繁的遇到，但我們又沒辦法用一套快速且有效率的系統來解決這一類開發上所遇到的溝通問題，這也是作者本人會想寫本系列的動機。

我想討論的不是「Codex 會不會寫程式」或是「ChatGPT 和其他模型比較是如何」，而是更實際的問題：ChatGPT 與 Codex 應該放在開發流程的哪個位置，才能節省時間，又保留人工決策、驗證證據與責任邊界？

我所說的「認真學」，不是背功能表

ChatGPT 與 Codex 的功能可能持續改變，因此這 30 天並不是學習如何操作，而是練習三項比較耐用的能力。

1. 交代上下文：當 AI 的結果不如預期時，是因為模型能力不足，還是你想要的結果其實有你不知道的一面？
2. 拆分責任：程式修改要交給 ChatGPT，還是 Codex？正確的工具能夠讓開發者有更好的開發體驗。
3. 要求證據：ChatGPT 與 Codex 顯示已完成，是真的完成了嗎？如何證明 AI 工具說的完成是真的完成？

這 30 天會走過哪些路線？

這個系列寫給參與軟體開發流程的讀者。路線會從心智模型、需求與設計、Codex 實作、整合工作流一路走到團隊治理。程式碼範例統一使用 Java，並視情境搭配 Maven／Gradle、JUnit 5 與 Spring Boot。

今天先做一件事：留下可驗證的紀錄

開始以前，先挑一項範圍不大的 Java 任務，例如補輸入驗證、增加測試，或修正能穩定重現的缺陷，並留下可比較的紀錄。

任務與驗收條件：
原本完成時間：
我交給 ChatGPT 的部分：
我交給 Codex 的部分：
人工修改或退回次數：
測試與審查結果：

Day 29 會再用這份基準線比較時間、返工、測試與人工介入程度。沒有基準線，「效率提升」很容易只剩主觀感受。

小結：先建立合作方法，再追求速度

這 30 天不是把責任交給工具，而是學會說清楚上下文、邊界與驗證方式。工作拆得清楚並留下證據，AI 才可能成為穩定的開發助力。

Day 02 會比較 ChatGPT 與 Codex 的工作對象、執行環境、產出形式與風險邊界，建立「什麼任務該交給誰」的判斷基準。